Simple Mail Transfer Protocol (SMTP) is the Internet standard for transmitting email messages from the sender to the recipient's mail server. This is accomplished through the use of mail transfer agents (MTAs) located on the mail server, and user agents (UAs) located on the user's local machine. The job of the MTA is to send and receive mail from other MTAs. The job of the UA is to interface with the MTA and to provide a user friendly environment for the end user.
The SMTP protocol provides a means for transferring messages from mail server to mail server. A server receiving such a transfer may be the message's final destination or merely a relay point. Alternative protocols (POP and IMAP) are used to retrieve email. The SMTP transfer is a three step process: authenticate the sender, send the mail, and close the connection. These processes ensue "lock step," meaning the sender sends a command which the recipient processes and responds to.
The examples that follow show SMTP commands sent between two SMTP mail transfer agents. When using PowerTCP Mail for .NET, all authentication and logging in is automatically handled by the Smtp component.
Prior to authentication, the receiver will (normally) listen on port 587 for TCP connections. Many receivers will also accept connections on port 25, but this port is intended for server to server relaying. Once a connection is made, the sender may issue the HELO command, followed by the sender's domain name. The recipient will in turn identify itself to the sender. The process will look something like this:
Recipient < wait for connection on port 587 > Sender: < make TCP connection > Sender: HELO sender.com Recipient: 250 server1.dart.com
The EHLO command initiates an alternative authentication method. This command is functionally similar to the HELO command, but indicates the sender's desire to use service extensions (these are a way to enhance SMTP and are covered later). Authentication using the EHLO command will look similar to this:
Recipient < wait for connection on port 587 > Sender: < make TCP connection > Sender: EHLO sender.com Recipient: 250 server1.dart.com 250-HELP 250-EXPN 250-XREMOTEQUEUE 250-ETRN 250-PIPELINING 250-SIZE
In this example, the response from the server is the same as with the HELO command except for the inclusion of supported service extensions. At this point the authentication stage is complete, and the sending mail process can continue. With pipe-lining the entire above process takes only one send and receive.
Once the sender is authenticated, the UA sends the mail message. This is a simple process involving three commands: MAIL FROM, RCPT TO and DATA. First, MAIL FROM, followed by the sender's address, is sent. If the recipient can accept mail, it responds positively with 250 OK. The sender then sends a series of RCPT TO commands, each followed by the address of a mail recipient. The receiver will either accept or reject each mail recipient. If a recipient is rejected, the mail transaction still continues. The sender then sends the DATA command with the actual message. The server responds with a 354 Intermediate reply, and will consider all succeeding lines to be the message. The message includes header fields with labels such as Date, Subject, To, Cc, and From, followed by the message body. When all data has been sent, the sender issues a <CRLF>.<CRLF>, informing the recipient that all data has been transmitted. The DATA command should fail only if the mail transaction was incomplete (for example, no recipients), or if resources are not available on the server. The entire process will look similar to this:
Sender: MAIL FROM: <Smith@Alpha.ARPA> Recipient: 250 OK Sender: RCPT TO: <Jones@Beta.ARPA> Recipient: 250 OK Sender: RCPT TO: <Green@Beta.ARPA> Recipient: 550 No such user here Sender: RCPT TO: <Brown@Beta.ARPA> Recipient: 250 OK Sender: DATA Recipient: 354 Start mail input; end with <CRLF> . <CRLF> Sender: Blah blah blah... Sender: ...etc. etc. etc. Sender: <CRLF>.<CRLF> Recipient: 250 OK
Once this stage is complete, the mail was sent and the connection must be closed.
The sender uses the QUIT command to close the connection. The recipient replies with 221, verifying that the connection is closed. This transaction will look similar to this:
Sender: QUIT Recipient: 221 closing channel < TCP connection ended >
The QUIT command signals the end of the mail process.
By default, commands and replies are composed of characters from the US-ASCII (7-bit) character set. If the server supports the extended protocol for an 8-bit byte (octet) transmission channel, it responds with this extension at greeting time. PowerTCP supports 8-bit binary transmissions. When the server accepts and forwards a message containing 8-bit data, any 7-bit only intermediate network segments that detect the impending message may refuse to receive the message. This generally results in the message being returned-to-sender.
SMTP supports other commands in addition to the authentication and sending commands, including:
The following example demonstrates a typical dialog between two mail transfer agents transferring mail using SMTP:
Recipient < wait for connection on port 25 > Sender: < make TCP connection > Sender: EHLO Recipient: 250 server1.dart.com 250-HELP 250-EXPN 250-XREMOTEQUEUE 250-ETRN 250-PIPELINING 250-SIZE Sender: MAIL FROM: <Smith@Alpha.ARPA> Recipient: 250 OK Sender: RCPT TO: <Jones@Beta.ARPA> Recipient: 250 OK Sender: RCPT TO: <Green@Beta.ARPA> Recipient: 550 No such user here Sender: RCPT TO: <Brown@Beta.ARPA> Recipient: 250 OK Sender: DATA Recipient: 354 Start mail input; end with <CRLF> . <CRLF> Sender: Blah blah blah... Sender: ...etc. etc. etc. Sender: <CRLF>.<CRLF> Recipient: 250 OK Sender: QUIT Recipient: 221 closing channel < TCP connection ended >
A communication log such as this one can be created using the Connection.Log event.